NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/std/c/282

Text File | 1996-08-06 | 4.2 KB | 82 lines

Newsgroups: comp.lang.c,comp.std.c
Path: blackbush.xlink.net!slsv6bt!slsv6bt!kanze
From: [e-mail] (James Kanze US/ESC 60/3/141 #40763)
Subject: Re: Integral conversion e.t.c. (was: Re: Hungarian notation)
In-Reply-To: [e-mail]'s message of Thu, 1 Feb 1996 16:56:57 GMT
Message-ID: <[e-mail]>
Sender: [e-mail]
Organization: SEL
References: <[e-mail]> <[e-mail]>
    <[e-mail]> <[e-mail]>
Date: 02 Feb 1996 12:33:45 GMT

In article <[e-mail]> [e-mail] (Michael Furman)
writes:

|> In article <[e-mail]>, [e-mail] says...
|> >
|> >In article <[e-mail]>
|> >[e-mail] (James Kanze US/ESC 60/3/141 #40763) writes:
|> ><snip>
|> >   I think the crux of Michael Furman's question lies therein.  Does the
|> >   standard require a diagnostic if the function main is not of one of
|> >   the two types given?
|> >

|>   Not exactly. My question was not about diagnostics, but about usage
|> of constructions that are not defined in standard.
|> There are two kinds of undefined behavior:
|> 1. When operation does not have any meaning. Example: assigning a value
|>   to dereferenced incorrect pointer. In such cases sometimes it is very
|>   hard or impossible (at least on some platforms) to check it even at
|>   execution time and it is really possible that hard disk will be
|>   reformatted as a result of such operations.
|> 2. When operation has meaning but can not be portable defined for all
|>   platforms. Example: all number conversions that depends on internal
|>   representation or some CPU specific (like rounding). But I have more
|>   clear example: "asm" keyword. I found it is defined in C++ draft and
|>   I believe it is defined in C standard.
|>   Was it inserted just to give programmers some way to implement undefined
|>   behavior (with some chance to have disk reformatted)? I do not think so.

|> In C++ draft standard there are two words used in such cases:
|> "undefined behavior" and "implementation defined behavior" - and I think
|> they are used accordingly for 1. and 2. As I understand now in C standard
|> there is no such clear division. But it does not mean that the problem
|> does not exist and I believe it is very wrong to claim that in every
|> case where behavier is not defined by C standard we may loose all
|> data from our hard disk!

I think that the C standard makes the same distinction.  In fact, in
general, I find it clearer that the C++ standard in this regard
(possibly due to the fact that it is finished, whereas the C++
standard isn't, or to the fact that C is a significantly simpler
language).

In fact, according to the standard, undefined behavior is just that:
undefined.  The standard makes no constraints.  In real life, of
course, implementations will behave in a somewhat more restricted
manner.  Thus, for example, I think it is safe to say that on no real
implementation will "i = i ++" actually reformat your disk (although
the probablity of it doing what you want is significantly less than
1).  The standard does not try and determine exactly what might really
happen in each distinct case of undefined behavior, however.

Note that implementations *are* allowed to offer extensions, and
define undefined behavior in an implementation specific manner.  An
implementation which defines, for example, that writing to the address
0 clears the screen, is perfectly legal.  If you write code uniquely
for that implementation, and you have to clear the screen, you will
dereference a null pointer.  If this is the only way of clearing the
screen on said implementation, and your application requires clearing
the screen, you will write code dereferencing a null pointer.

That doesn't make such code any less undefined with regards to the
standard.
--
James Kanze         Tel.: [phone]        email: [e-mail]
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils, Θtudes et rΘalisations en logiciel orientΘ objet --
                -- A la recherche d'une activitΘ dans une region francophone